
13. The device of claim 12, wherein: 
th e control information compris e s an XML format; 

- the d e vic e has means for parsing comprises an XML parser; and 

- the d e vic e has means for retrieving and using comprises an XML interpreter. 

A clean copy of the amended claims is included as part of the substitute specification. 



REMARKS 

The Office Action of 08/20/2002 has been carefully considered. In response 
thereto, the specification and claims have been amended for greater clarity. A substitute 
specification is submitted herewith. Reconsideration is respectfully requested. 

Claims 1-13 were objected to for various informalities. These informalities have 
been corrected by the present amendments. 

Claims 7-10 were rejected under 35 U.S.C. 101 as being directed to non-statutory 
subject matter. Claim 7 has been cancelled in favor of new claim 17, which is believed to 
present statutory subject matter. 

Claims 1-5 and 12 were rejected as being anticipated by or unpatentable over 
Gelman. Claim 6-9 were rejected as being unpatentable over Gelman in vie wof Cohen. 
Finally, claims 10 and 13 were rejected as being unpatentable over Gelman in view of 
Girardot. Claims 1 and 12 have been cancelled in favor of new independent claims 14 
and 20. Reconsideration is respectfully requested. 

The present invention relates to a flexible, client-driven method of media retrieval 
and presentation, as well as an intelligent client device for carrying out such method. In 
an exemplary embodiment, the method uses a parseable control information file such as 
an XML file. Media retrieval and presentation begins with retrieval and parsing of the 
control information file. A control script is then run by an XML interpreter, using output 
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from the XML parser. In general, the control script retrieves files, or segments of the 
media presentation, from one or more servers in a computer network for sequential play- 
out. Insofar as the particulars of which files are retrieved, when and from where, 
however, the control script offers great flexibility. For example, two or more alternative 
files may be provided corresponding to the same section of a media presentation, with the 
client device selection between the alternatives based on device capability, for example, 
or network conditions, or other considerations. 

Gindele does not teach or suggest such a modified prefetch strategy. Gindele does 
describe prefetch and a LRU (least recently used) replacement algorithm. A similar LRU 
algorithm as applied in Gindele to cache lines is applied in a subsidiary aspect of the 
invention to cache buffer registers (as opposed to cache lines themselves). - 

Nevertheless, the prefetch strategy of Gindele is clearly different from that of the 
present invention. As described in the second paragraph, lines 4-9, a prefetch is initiated 
by the first CPU reference to a block after it is put into the cache, the prefetch transferring 
to the cache the next sequential block after the block having the cache hit. No 
consideration is made, as in the present invention, of where in the cache line (or block) 
the hit occurred. Accordingly, independent claims 12 and 13 are believed to patentably 
define over the cited reference. 




6 



Dependent claims 2-5, 15, 16, 18, 19, 21 and 22 are also believed to add novel and 
patentable subject matter to their respective independent claims. Withdrawal of the 
rejection and allowance of claims 2-6 and 12-22 is respectfully requested. 



Respectfully submitted, 




Michael J. Un£Reg. 33,089 



Dated: October 1,2002 






PARTITIONING OF MP3 CONTENT FILE FOR EMULATING STREAMING 



FIELD OF THE INVENTION 



The invention relates to content and/or control communications between multiple 
computer systems, or to such communications between computer systems and consumer devices. 



Specifically, the invention relates to communication constrained by bandwidth or limited by data 
processing resources available to the receiving system or device, especially if the 
communications are received by the user in real time. The type of communications can be, e.g., 
broadcast, multi-cast or point-to-point. 

10 

BACKGROUND ART 

Consider current major technologies for delivering digital content, such as audio, video, 
etc. The streaming method for audio, e.g., RealAudio by RealNetworks, consists of playing-out 
audio at a client device, while constantly sending data from the server to the client. The 

15 technology provided by RealNetworks comprises an encoder, a server, a splitter/cache and a 
player system with two-way intelligence to resolve network congestion, lost packet conditions 
and negotiate complex internet protocols. More specifically, the known technology comprises an 
automatic, variable bit-rate encoding and delivery system for audio and video. The system scales 
to megabit connection rates and dynamically adjust the transmission rate as delivery rate varies 

20 due to network congestion. The format and the encoding/decoding methods of the data are 

proprietary. The server and the client synchronize receiving and playing in a way pre-defined by 
the particular architecture. The communication stack software is tightly coupled to the 
interpretation layer (application and user interface (UI)). Manufacturers of such technology 
promote high level of integration between client and server software, as a complete vertical 

25 solution. This approach mostly excludes third parties from developing custom server software 
(e.g., advertizing, services) and/or client applications (UI, special effects, etc.). 

Another known method is downloading of a content file from a remote computer with 
subsequent play-out on the client. MP3 is a widely known audio data format used within the 
downloading context. There are other data formats, e.g., MP4 for video data etc. The major 

30 advantage of the above mentioned method is its open data standard approach. As long as the 

right format of the content file is observed during encoding, client and server software/hardware 
manufacturers are free to develop their own solutions/products. 

A major problem with the complete download approach is the inherent latency: there is a 
delay between the beginning of the download and the start of the play-out. The larger the file and 

35 or smaller the communication bandwidth, the longer it takes to transfer the content from the 
server to the client. This is particularly undesirable in consumer electronics systems, where 
perceived delay is detrimental to market acceptance of an open architecture. 
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SUMMARY OF THE INVENTION 

It is an object of the invention to provide an open architecture solution for content 
delivery in a download approach that allows for a low or negligible play-out latency. 

To this end the content file is split into multiple parts. Each part or segment requires a 
relatively short download time. Therefore, the play-out latency is determined by the download 
time of the first part. The size of the individual part can be determined by the communications 
bandwidth, e.g., through pinging for a latency-check. The client device/application receives 
control information about the content. This control information comprises, for example, 
information relating to the size and memory location of the whole file as well as of it parts at the 
server. If the client is not capable of processing split data, it proceeds with the traditional 
approach, i.e., downloads the whole file and then plays it out. In case the client is capable of 
processing parts of the content, it uses the relevant control information about the parts in order to 
continue downloading data, while playing. Data play-out, also called "rendering", is 
computation-intensive, since it requires a plurality of decoding operations. Data download is 
bandwidth-intensive. Accordingly, simultaneous play-out and downloading do not significantly 
compete for the same system resources. This separation between downloading and processing 
can be efficiently used in a multi-process and/or multi-thread environment. 

Preferably, the information contains references to the file location as well as references to 
the locations of the parts. The intended bandwidth information is associated with the parts. The 
client may make its own decisions regarding how many parts to download before the start of the 
play out (execution). 

The parts can have different data formats. The format of some of the parts can be 
proprietary. Information about alternative content parts, regarding bandwidth, format, location 
access options, etc., can be provided. Content parts can physically reside on different servers. 
Content can be split into parts consistent within the semantics of the content, e.g., end of musical 
phrase, paragraph, target control device, etc. A third party may insert its own content parts in 
between the original content parts. The third party parts contain, for example, advertisements, 
commentary, customization options. The format of parts for play-out may be chosen according to 
user-related information, e.g., personal preferences, level of access to premium services, quality 
of the equipment, bandwidth sharing/fluctuation conditions, etc. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The invention is explained in further detail and by way of example with reference to the 
accompanying drawing wherein: 

Fig.l is a flow diagram illustrating the various steps in a method according to the 
invention; and 

Fig.2 gives an example of control code. 
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Throughout the Figures, same reference labels indicate similar or corresponding features. 

PREFERRED EMBODIMENTS 

The invention enables emulating the streaming of files while using a download approach. 
5 Fig. 1 illustrates a flow diagram 100 with various steps involved in the playing-out of a 
segmented file at the client. 

In step 102, the client contacts the server selects the particular content file and downloads 
the control information that enables the retrieving and playing out of the segmented file. The 
control information describes the locations, e.g., URL's, and size of the various file segments, 
10 and provides, e.g., UI functionalities at the client. In this example, the control information is 
coded in XML. 

In step 104 the XML code is parsed. Parsing of XML is well known in the art. A person 
skilled in the art can download an XML interpreter, including source code, from the Internet, see 
e.g. www.ibm.com/xml. Thus, the client is enabled to get information about the content 

15 information and the URLs of the first and subsequent file segments. 

In step 106, the first file segment is downloaded for play-out. Communicating with a 
remote server is a well known technology. For example, Java 2.0 provides a set of standard 
classes that enable retrieving a remote file into a buffer or as a stream, (s ee , e .g., www.sun.com 
Java 2.0 java.io.* packag e docum e ntation). 

20 In step 108, the rendering of the first segment is started. The buffered content of the first 

segment is forwarded to a decoding/playing module. The decoding/playing module decodes the 
file format, e.g., MP3. The playing of the supplied stream of bits involves a number of standard 
operating system calls to its drivers -a technique well known in the art. 

In step 110, the next file segment is downloaded at the client and stored in a buffer while 

25 the previous file segment, here the first file segment, is being played out. One option is to have 
the downloaded files buffered in a sequence or linked list of buffers. This functionality is 
typically provided by the operating system of the client. For example, MS Windows family of 
products creates a memory buffer associated with the file every time an API call opens the file. 
Alternatively, in a thread- and/or process-rich environment, several threads and/or processes can 

30 be organized to independently retrieve file segments, while playing out the content of other 

segments. Working with threads is a skill common for software engineers. For example, Java 2.0 
from Sun Microsystems provides classes supporting multiple threads, (s ee , for e xampl e , 
java.lang.thr e ad and r e lated docum e ntation) Similarly, Microsoft SDK for the Windows family 
of products makes thread- or process-related functionalities available to programmers. 

35 Upon completion of playing out the first segment, the second segment is passed on from 

the buffer to the decoding/playing module. This can be implemented by means of., e.g., a linked 
list. As known, a linked list is a data structure wherein each element (here: segment) has content 
data and a pointer to a next element (here: next segment). 
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The decoding/playing module has to decode the file format. The decoding program 
represents a standard task to a person skilled in the art to program a decoding procedure 
according to a widely published standard (MP3, etc.). The playing of the supplied stream of bits 
involves a number of standard operating system calls to its drivers - a technique well known in 
5 the art. 

Fig.2 gives an example of information-describing content coded in XML. The code 
fragment labels the segments as having a title "The best ever music" performed by "V.R. 
Famous" and having several parts. The segment labeled "parti" is in a preferred format and 
described the length of the part, e.g., in bytes, the format, the minimum bandwidth required for a 
10 connection, and the location on the Internet. An alternative first part is labeled "parti alt" having 
a different length, different format, different minimum bandwidth requirement, and a different 
location. The XML code can be combined with XSL for generating a user level UI at the user's 
client. The client thus can automatically choose the format compatible with the client's play-out 
capabilities. 

15 When the client has selected the proper file, either the one of which the first part is 

represented here as in the preferred format or the one in the alternative format, the content of the 
first part is downloaded from the location specified and playing out is started automatically under 
application control. Combining multiple sequenced inputs is well understood in the industry. For 
example, Java JDK v. 1.2 from Sun Microsystems, Inc. provides a class 

20 java.io.SequencelnputStream (see 

http://iava.sun.eom/products/idk/l .2/docs/api/iava/io/S e qu e nceInputStr e ams.html ) as a standard 
component of the io class library. SequencelnputStream represents the logical concatenation of 
other input streams. It starts out with an ordered collection of input streams and reads from the 
first one until end of file is reached, whereupon it reads from the second one, and so on, until end 

25 of file is reached on the last of the contained input streams. An object of the 

java.io. SequencelnputStream class can be initialized by, e.g., enumeration (see 
http://iava.sun.eom/product s /idk/l.2/docs/api/iava/util/Enum e ration.html ) of objects of the 
InputStream class (s ee http://iava.sun.eom/products/jdk/l .2/docs/api/iava/io/InputStr e am.htm^ . 
This abstract class is the superclass of all classes representing an input stream of bytes, including 

30 the class FilelnputStream (s ee http://java.sun.eom/products/jdk/l .2/docs/api/java/io 

Fil e lnputStr e am) . In case of the downloading of multiple file parts, an application can create 
instances of the FilelnputStream class from local temporary files into which the parts are being 
downloaded. The contents of those multiple local files will be supplied to the Sequencer. The 
rendering component of the application will read the information out it as if it were just a single 

35 local file. 

The segmentation of the content file into separately downloadable segments enables a 
third party, such as a service provider, to insert between two segments specific content 
information, e.g., advertisements to be rendered on the client's display. 
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During operation, the client application could select a next segment in a different format 
for the same content to adapt to changing circumstances, e.g., lower bandwidth due to network 
congestion. Also, the user could be prompted to subscribe to a service that as a demo lets the user 
download only the first segment in a high quality and the next segments in a lower quality. The 
5 combination of XML and a corresponding parser and interpreter at the client controls the 
downloading and playing out as explained above. Accordingly, the client pulls the content 
segments from the locations indicated in the XML control information for buffering and 
subsequent play-out. 

The implementation of a client in this client-server architecture can be done in a variety 

10 of ways. A first example is a hardware-based single-purpose device, similar to the Rio MP3 

player by the Diamond Corp. In order to accommodate the method of the invention, the player 
needs, in addition, an XML parser, the ability to interpret XML and the ability to download and 
play-out coontent segments sequentially. A second example is to implement the method of the 
invention as a software application on a multi-purpose computing device, e.g., a PC or a set top 

15 box. The device has the software implementing the functionalities mentioned above. In a 

graphics-rich environment, multiple GUPs are represented to the user for further customization. 
The following co-pending applications are incorporated herein by reference: 
U.S. serial no. (Attorney docket PHA 23,768) filed 9/27/99 for Raoul 

Mallart for SCALABLE SYSTEM FOR VIDEO-ON-DEMAND. This patent document relates 

20 to a Video-on-Demand service (VOD) that is emulated in a Near-Video-on-Demand (NVOD) 

architecture. Content information is made available to an end-user in the NVOD architecture. An 
introductory portion of the content information is stored at the end-user's equipment, e.g., by 
downloading overnight. During playing out of the introductory portion at the end-user enabling 
the content information supplied in the NVOD architecture is buffered at the end-user's 

25 equipment. The equipment is controlled to switch from playing out the introductory portion 
stored to playing out the buffered content information. 

U.S. serial no. 09/189,534 (Attorney docket PHA 23,528) filed 1 1/10/98 for Eugene 
Shteyn for CONTENT SUPPLIED AS SOFTWARE OBJECTS FOR COPYRIGHT 
PROTECTION. This document relates to supplying content information such as a movie, an 

30 audio file or a textual message to an end-user in a software object. The object has an 

encapsulated procedure for end-user access of the content information in a runtime environment. 
The object can specify time frame for and manner wherein the content information is to be 
accessed. Since the procedure is encapsulated in the object together with the content data, and 
since transport of the object over the Internet is done after serializing, an adequate degree of 

35 security is provided against unauthorized play-out or copying. 

U.S. serial no.09/149,950 (Attorney docket PHA 23,495) filed 9/9/98 for Raoul Mallart 
for REAL TIME VIDEO GAME USES EMULATION OF STREAMING OVER THE 
INTERNET IN A BROADCAST EVENT. This patent document relates to emulating streaming 
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of animation data over the Internet to a large number of clients in a broadcast application on a 
client-server network. The animation is considered a sequence of states. State information is sent 
to the clients instead of the graphics data itself. The clients generate the animation data itself 
under control of the state information. The server and clients communicate using a shared object 
5 protocol. Thus, streaming is accomplished as well as a broadcast without running into severe 

network bandwidth problems. This is approach is used to map a real life event, e.g., a motor race, 
onto a virtual environment in order to let the user participate in a virtual race against the real life 
professionals, the dynamics of the virtual environment being determined by the state changes 
sent to the user. 

10 U.S. serial no. 09/138,782 (Attorney docket PHA 23,491) filed 8/24/98 for Raoul Mallart 

and Atul Sinha for EMULATION OF STREAMING OVER THE INTERNET IN A 
BROADCAST APPLICATION. In a broadcast application on a client-server network the 
streaming is emulated of animation data over the Internet to a large number of clients. The 
animation is considered a sequence of states. State information is sent to the clients instead of the 

15 graphics data itself. The clients generate the animation data itself under control of the state 

information. The server and clients communicate using a shared object protocol. Thus, streaming 
is accomplished as well as a broadcast without running into severe network bandwidth problems. 

U.S. serial no. 09/283,545 (attorney docket PHA 23,633) filed 4/1/99 for Eugene Shteyn 
for TIME- AND LOCATION-DRIVEN PERSONALIZED TV. This document relates to a 

20 service for personalized video recorders such as the one from TiVo-Philips. The recorder has a 
hard-disk that serves as a random-access buffer. 
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1 . A method of enabling to emulate streaming of a file over a data network to a client, the 
5 method comprising: 

partitioning the file into multiple segments; 

enabling the client to download a first one of the segments for playing out; 

enabling the client to download a next one of the segments while playing out a current 

one of the segments: 

10 enabling the client to buffer the next segment while playing out the current segment; and 

enabling the client to start playing out the buffered next segment upon compl e tion of the 

playing out of the current segment. 

2. The method of claim 4- 14, wherein the-partitioning of media presentation information 
15 between the multiple related files is determined by information about the client. 

3. The method of claim 4- 14, wherein the-partitioning of media presentation information 
between the multiple related files is determined by information about the computer network. 

20 4. The method of claim 4- 14, wherein the file- media presentation comprises an audio file 
presentation . 

5. The method of claim 4- 14, wherein the file- media presentation comprises a video file 
presentation . 

25 

6. The method of claim 4- 14, wherein the-partitioning of media presentation information 
between the multiple related files comprises adding re s pectiv e is described within the control 
information file using tags corresponding to respective ones of the segments files . 

30 7. An electronic file comprising information content partitioned into multiple segments that ar e 
s eparately downloadab l e over a data network, the file comprising control information for 
enabling to play out a fir s t one of the s egments upon downloading, enabling to buffer a second 
one of the segments while the first segment is being played out and enabling a seamless 
tran s ition between the playing out of the first and the second segments. 

35 

8. The file of claim 7, wherein a respective one of the multiple segments comprises respective 
control information. 

9. The file of claim 7 implemented as a linked list. 
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10. Th e fil e of claim 7 comprising th e control information in XML format. 

1 1 . A d e vic e for play - out information cont e nt r e c e iv e d ov e r a data network from a s e rv e r, 
wher e in: 

5 - the information cont e nt compris e s multipl e s e gments; 

the d e vic e is capabl e of downloading a first on e of th e s e gm e nts from the serv e r for playing 

r\i if ♦ 

th e devic e is capabl e of downloading a n e xt on e of th e s e gm e nts whil e playing out a curr e nt 
on e of th e s e gm e nts; 

10 th e d e vic e is capabl e of buff e ring th e n e xt s e gm e nt while playing out th e curr e nt s e gm e nt; and 
th e d e vic e is capabl e of starting to play out th e buff e r e d n e xt s e gm e nt upon compl e tion of th e 
playing out of the curr e nt s e gm e nt. 

12. The device of claim 44 18, wherein: 

15 th e cont e nt information is acc e ssibl e through control information provid e d to th e d e vic e ; and 

- the device is capabl e of interpreting interprets the control information to retrieve th e s e gm e nts 
multiple files from the server- computer network for sequential play-out. 

13. The device of claim 12, wherein: 

20 th e control information compris e s an XML format; 

- the d e vic e has means for parsing comprises an XML parser; and 

- the d e vic e has means for retrieving and using comprises an XML interpreter. 
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14. A method of. at a client device, forming a media presentation from multiple related files, 
including a control information file, stored on one or more server computers within a computer 
network, the method comprising: 

downloading the control information file to the client device: 

the client device parsing the control information file: and 

based on parsing of the control information file, the client device: 

retrieving a first file and using contents of the first file to begin a media 

presentation: 

concurrent with the media presentation, retrieving a next file: and 

using content of the next file to continue the media presentation. 

1 5. The method of claim 14 wherein the control information file is an XML file. 

16. The method of claim 15, wherein the XML file identifies multiple alternative files 
corresponding to a given segment of the media presentation, further comprising selecting and 
retrieving one of the multiple alternative files. 



1 7. A method of storing media presentation information within a computer network including 
multiple server computers, the method comprising: 

storing on a server computer a control information file of a format to be parsed by a client 

device: and 

storing on one or more server computers multiple related files accessible by the client 

device to, based on parsing of the control information file, form a media presentation from the 
multiple related files. 

1 8. The method of claim 1 7, wherein the control information file is an XML file. 
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19. The method of claim 1 8, wherein the XML file identifies multiple alternative files 
corresponding to a given segment of the media presentation. 



20. A client device for forming a media presentation from multiple related files stored on 
server computers within a computer network, comprising: 

means for downloading files to the client device; 

means for parsing a control information file; and 

means for, based on parsing of the control information file: 

retrieving a first file and using contents of the first file to begin a media 

presentation; 

concurrent with the media presentation, retrieving a next file: and 

using content of the next file to continue the media presentation. 

21 . The method of claim 20, wherein the control information file is an XML file. 

22. The method of claim 21, wherein the XML file identifies multiple alternative files corresponding to a given 
segment of the media presentation, the means for retrieving comprising means for selecting and retrieving one of the 
multiple alternative files. 
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ABSTRACT 

An electronic file, e.g., an MP3 file, is partitioned into a sequence of segments at the server side. 
The first segment is played out upon downloading. While the first segment is being played out, 
the second is being downloaded and buffered so that it is available when the play out of the first 
segment is completed. While playing out a current one of the segments, next one(s) of the 
segments are being downloaded and buffered. This partitioning and sequential play out enables 
to emulate streaming of a file and to minimize latency while downloading an electronic file. 
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